Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9703/000050_owner-urn-ietf _Mon Mar 24 17:54:19 1997.msg

Internet Message Format | 1997-04-01 | 5KB

Received: (from daemon@localhost)
    by services.bunyip.com (8.8.5/8.8.5) id RAA25578
    for urn-ietf-out; Mon, 24 Mar 1997 17:54:19 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
    by services.bunyip.com (8.8.5/8.8.5) with SMTP id RAA25570
    for <[e-mail]>; Mon, 24 Mar 1997 17:54:16 -0500 (EST)
Received: from lysithea.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA14460  (mail destined for [e-mail]); Mon, 24 Mar 97 17:54:14 -0500
Received: (from sollins@localhost) by lysithea.lcs.mit.edu (8.6.9/8.6.9) id RAA03578; Mon, 24 Mar 1997 17:54:00 -0500
Date: Mon, 24 Mar 1997 17:54:00 -0500
Message-Id: <[e-mail]>
From: "Karen R. Sollins" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
In-Reply-To: <[e-mail]> (message from Ron
    Daniel on Fri, 06 Dec 1996 10:48:27 -0700)
Subject: Re: [URN] comments on Sollins' requirements draft
Sender: [e-mail]
Precedence: bulk
Reply-To: "Karen R. Sollins" <[e-mail]>
Errors-To: [e-mail]

Ron,

I am pulling a bit out of a message you sent out shortly after I put
out the requirements doc, because it brings up several questions.  In
general the rest of what you said was a good set of points and I'm
working on them.  Meanwhile, here's what you said:


   This implicit establishment of the security policy that must be obeyed
   by URN resolvers shows up in several other places. There are many
   sentences where you say that something "must" exist which I would
   like to change to saying "must be capable of supporting". For example
   you say that "There needs to be an authoritative version of each hint,
   and it must support change control limited only to those principals
   with the right to modify it". I would prefer a different wording:
   "Each resolution hint shall have an authoritative instance. It
   must be possible to restrict changes to the authoritative hint
   according to the security policy of the organization issuing the hint.
   Propagation of changes to the authoritative version to any sites mirroring
   it must be capable of being carried out in a fashion consistent with
   the security policy governing the operation of the mirroring service."
   (Actually, I would prefer something less awkward, but I digress. :-)

And my questions are:

1) What did you mean by "resolution hint"?  My suspicion is that you
meant a hint that leads to a resolution server, and I will assume that
for my real question, but I realized that I'd better be sure we're on
the same wavelength.

2) Is it necessary (and this a question you could have asked of me as
well) that there be an authoritative version of every hint?
Personally I don't think so.  I believe that there may be hints that
are intended just to be helpful, but non-authoritative.  I make a copy
of a resource and make it available to anyone who cares to use it.  I
put a hint out.  I may not want to be viewed as "authoritative" in any
way and it certainly doesn't come from anyone who has authority over
the resource.  Or, in another circumstance, I am the authority for a
resource and the network has become partitioned so that both the
"authoritative resolution server" for my resource and my storage
system from which it is available are not accessible.  I reach a
temporary agreement with a friend to make my resource available
non-authoritatively for a short while and provide non-authoritative
resolution to this non-authoritative copy, until the network is fixed.
I may want to get the hints for this out as quickly and simply as
possible, which may mean non-authoritatively.  Should we disallow
that?  (I think not, so in that sense, I think both of us went
overboard a little.)

3) If I assume that the answer to question 1 is that a "resolution
hint" is a hint for a resolution service, then as I read your
suggested re-writing the RDS must provide whatever security policy
each organization wants (with no restrictions) for its hints.  I
believe that we can only take a less restrictive position and say that
there are certain policies and levels of security that an RDS can
provide and an organization can choose among them.  If these do not
provide the degree and type of security that the organization feels it
needs then I guess they won't use our service.  But, I don't believe
that we can make the unconditional requirement that says, "It must be
possible to restrict changes to the authoritative hint according to
the security policy of the organization issuing the hint."  Is that
really what you meant to say?

4) One last minor question about the following sentence, "Propagation
of changes to the authoritative version to any sites mirroring it must
be capable of being carried out in a fashion consistent with the
security policy governing the operation of the mirroring service."
Shouldn't this                                 ^^^^^^^^^

be "mirrored"?

            Karen